Repository navigation
✨ feat: add a passkey type - #82
Merged
Merged
Conversation
A record of a passkey, not the passkey. Its private half never leaves the authenticator — that is the point of one — so no vault can hold it, and a web page cannot become the authenticator that signs with it. What people lose track of is where each one lives and what gets them back in when that device is gone, so the type records exactly that: the site, the account, the authenticator, the device when the key does not sync, when it was created, and the recovery codes. The authenticator and the device are plain text on purpose. Search reads non-secret fields, so typing "yubikey" lists what that key opens, which is the question someone asks the day they lose it. The first draft put "yubikey" among the type's keywords, which would have made every passkey answer that search, iCloud ones included; the keywords now say what the type is (webauthn, the names Apple, Google and Microsoft give it in Portuguese) and never where one lives.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A record of a passkey, not the passkey.
Why a record
The private half of a passkey never leaves its authenticator — that is the point of one — so no vault can hold it, and a web page cannot register as the authenticator that signs with it (that takes a browser extension or a native credential provider). So Keeper cannot be where a passkey lives, and this type does not pretend to be.
What people actually lose track of is where each one lives, and what gets them back in when that device is gone. That is what the type records:
registeredAt, notcreatedAt, to stay clear of the item's own fieldThe feature hiding in the search
Search indexes every non-secret field, so the authenticator and the device are searchable. Typing
yubikeylists exactly what that key opens — the question someone asks the day they lose it.My first draft broke that without noticing: I had put
yubikeyandchave de segurançaamong the type's keywords. A keyword matches every item of the type, so every passkey would have answered that search, iCloud ones included, and the answer would have been a lie. The keywords now describe the type —webauthn,fido2, and the names each platform uses in Portuguese (chave-senhafor Apple,chave de acessofor Google and Microsoft) — and never where one lives. A comment in the model says why.Tests
Three unit tests in
search.test.ts, with a YubiKey passkey beside an iCloud one:yubikeyreturns the YubiKey one and only it;Three mutations, three failures — including putting my own mistake back:
yubikeyas a type keywordmultiline(indexable)Four smoke checks create a passkey through the real form: the type is offered under development secrets, the wizard filter finds it by
chave de acesso(and hides Chave SSH), the form renders where-it-lives and recovery, and after saving, searchingyubikeyin the real UI returns it with the account on the row. The smoke comment is explicit that it proves the wiring, not "only that" — its vault holds a single passkey, so the unit test carries that half.npm test390 green · build clean · smoke 234 green, up from 230.